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BACKGROUND 

Field of the Invention 

[000 1 ] The present invention relates generally to application software development, 

configuration management, and deployment. More specifically, the present invention 
relates to program management software that allows an organization to effectively 
deploy new or updated software only after the software has been tested for quality 
and durability. 
Background of the Invention 

[0002] Configuration management for development and deployment of application 

software can be a complex and time-consuming task in environments where software 
developers are constantly updating software used to support operational business 
requirements. For example, many organizations today employ large teams of 
software developers to create and maintain applications needed to maintain a cutting- 
edge in their respective markets. Oftentimes, there is a need to continually improve 
or expand the capabilities offered to customers via the applications. In such dynamic 
software development environments, systems and methods for managing 
development and deployment of application software can be critical to the success of 
the organization. 

[0003] It is common knowledge in the art that software development should follow a 

few basic principles. For example, it is generally accepted that a requirements phase 
should be the first step in any software development project. During this phase, the 
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desired functionality of the software is defined and well as its operating 
environments, timelines for deployment, budgets, and the like. The next phase in a 
software development process typically involves application developers actually 
writing code to meet the requirements. In this phase, the developers may consider 
questions or issues such as the choice of the software development environment, the 
programming techniques to be implemented, and the like. 

[0004] Once the application code has been written, it needs to be tested. In many 

environments, the initial testing is performed by the developers themselves. At some 
point in the process, the application may be turned over to a quality assurance (QA) 
group for further testing. The application will be deployed on operational systems 
only if the code passes QA testing. 

[0005] While these phases are commonly known to software developers, a problem 

exists in enforcing the procedures. That is, for a variety of reasons, the new code may 
not have been fully tested prior to being deployed. For example, if a code change 
appears simple, the developer may not consider how the change may impact other 
applications running in the production environment. In other cases, a short deadline 
may force a developer to deploy software before it has been fully tested. Another 
problem with managing software configuration may be the sheer number of 
developers working on a project. The project may be so large that it is broken down 
into several components, such that each component is independently developed, 
tested and deployed. In such cases, it becomes a very difficult process to manage 
each component to ensure that all testing has been accomplished prior its deployment. 
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[0006] Conventional software configuration management applications have been 

used to track software configuration. Such management applications may be used to 
determine the versions of software on a system and may be used to track other 
software development tasks. However, conventional configuration management 
applications do not include enforceability. That is, such applications may be used to 
help a manager to track changes to a system. However, applications do not provide a 
common framework within which developers, testers, and configuration managers 
can work to manage the entire software development and deployment process. 

[0007] Another problem with conventional configuration management software is the 

lack of a user-friendly interface. Many configuration management software is 
difficult to understand and does not provide high-level visibility into the status of 
individual software components. 
SUMMARY OF THE INVENTION 

[0008] The present invention solves the foregoing problems associated with 

conventional software application configuration management and deployment 
systems by providing a system and method for a web-based software development 
and deployment tool. 

[0009] A development and deployment tracking tool according to the present 

invention allows a software development organization to manage a plurality of 
software releases. The tool is made up of a series of lists or databases tracking 
various information related to the software releases and individual software 
components making up the releases. One list identifies the plurality of software 
releases, including a release identification and a source type for each release. 
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Another list relates to the individual software components, including information 
such as a build script and a script type associated with each component. Another list 
identifies a plurality of application operating environments including an environment 
type associated with each environment. Another list identifies a plurality of nodes 
including an environment selected from the environment list. Another list identifies a 
plurality of users of the development and deployment tool and associates a role 
defining each user's access rights to the development and deployment tracking tool 
The development and deployment tracking tool includes a user interface for 
receiving a build request from a user, including information such as a release name, a 
component name, and a target environment. The user interface allows the user to 
select the release name, the component name, and the target environment from the 
entries defined in the respective lists. When a build request is received from a user, 
the development and deployment tracking tool checks the user list to verify that the 
user's role allows the request, and the development and deployment tracking tool 
executes the build script associated with the component, and updates a status 
associated with the build request. In an embodiment the development and 
deployment tracking tool sends an email message to one or more users when the build 
request has been completed. 

Examples of environment types include a common development environment, 
a pre-production environment, a production environment, a sandbox environment, a 
system test environment, and an undetermined environment type. Examples of roles 
include a developer, a configuration manager and a quality assurance tester. 
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[001 2] An embodiment may include a user interface for receiving a test approval 

result. The test approval result may be passed via a notification message to one or 
more users for action. For example, if the component fails a test, the developer may 
receive a notification indicating the result and providing comments to help identify 
the problems to be corrected. 
BRIEF DESCRIPTION OF THE DRAWINGS 

[0013] Figures 1 A and 1 B are flow diagrams showing steps that may performed in 

an embodiment of the present invention. 

[0014] Figure 2 is a screen shot showing an exemplary view of a user interface that 

may be used in a development and deployment tracking tool according to the present 
invention. 

[0015] Figures 3 A and 3B are screen shots showing exemplary user interface forms 

for entering application development data to define a new release and component. 
[0016] Figure 4 is a screen shot showing an exemplary user interface form for 

entering application development data to define a new environment within the 

development and deployment tool. 
[0017] Figure 5 is a screen shot showing an exemplary user interface form for 

entering application development data to define a new node within the development 

and deployment tool. 

[001 8] Figures 6 A and 6B are screen shots showing exemplary user interface forms 

for establishing an environment chain in an embodiment of the present invention. 
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[001 9] Figures 7 A and 7B are screen shots showing exemplary user interface forms 

for entering and updating application development data to define a new user within 

the development and deployment tool 
[0020] Figure 8 is a schematic diagram showing an exemplary menu choice that may 

be provided under a "CM Administration" function of the development and 

deployment tool. 

[0021] Figure 9 is a schematic diagram showing an exemplary menu choice that may 

s e be provided under a "Build" function of the development and deployment tool. 

P [0022] Figure 10 is a screen shot showing an exemplary user interface form for 

4-- initiating a sandbox build request within the development and deployment tool, 

jp [0023] Figure 1 1 is a screen shot showing an exemplary user interface form for 

completing a sandbox build request within the development and deployment tool. 
n [0024] Figure 12 is a screen shot showing an exemplary user interface form for 

H initiating a common development build request within the development and 

deployment tool 

[0025] Figure 13 is a screen shot showing an exemplary user interface form for 

completing a common development build request within the development and 
deployment tool. 

[0026] Figure 14 is a screen shot showing an exemplary user interface form for 

grading a component within the development and deployment tool 

[0027] Figure 1 5 is a schematic diagram showing an exemplary menu choice that 

may be provided under a "Build" function of the development and deployment tool 
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[0028] Figure 16 is a screen shot showing an exemplary user interface form for 

initiating a system test deployment request within the development and deployment 
tool. 

[0029] Figure 17 is a screen shot showing an exemplary user interface form for 

initiating a pre-production deployment request within the development and 
deployment tool 

[0030] Figure 1 8 is a screen shot showing an exemplary user interface form for 

initiating a production deployment request within the development and deployment 
O tool. 

[003 1 ] Figure 1 9 is a screen shot showing an exemplary user interface form for 

If modifying a build request status report within the development and deployment tool. 

[0032] Figure 20 is a table of data elements that may be associated with a software 

Ly release in an embodiment of the present invention, 

if [0033] Figure 21 is a table of data elements that may be associated with an 

t U application environment in an embodiment of the present invention. 

[0034] Figure 22 is a table defining terms used in the present detailed description of 

the invention. 

DETAILED DESCRIPTION OF THE INVENTION 

[0035] The development and deployment tool described herein provides a framework 

for managing and enforcing a software application development and deployment 
process. The tool provides users with a system and method for automating the 
software builds for each phase of the development and deployment cycle. As known 
in the art, a software build is the result of the compiling of any necessary code. 
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Developers, configuration managers, quality assurance groups, and others may use 
the tool to track the status of each individual component of a software application. 
The tool may be configured to provide different levels of access to different users, 
depending on the "role" the user is assigned in the system. 

As a component moves from one phase to the next within the development 
and deployment cycle, email notifications may be sent to interested parties. This 
feature can be used to help keep a project on track by keeping everyone informed as 
to the status of the project. 

As indicated above, the development and deployment tool may also be used to 
enforce the configuration management (CM) policy for an organization. For 
example, if the CM policy requires all code to be tested in numerous environments, 
the tool may be used to graduate the application to each level as it passes the earlier 
testing levels. If the application fails any of the required tests, the development and 
deployment tool can be used to send the build back to the developers for corrections. 

Because the development and deployment tool is web-based, the user 
interface may be implemented as a graphical user interface (GUI) to receive needed 
information from users as required. The GUI may be presented as one or more 
windows and the windows may comprise one or more forms (also referred to herein 
as "views") that a user may use to enter and submit data related to an application. 
Also, as a web-based tool, the system is not limited to any one hardware 
configuration and may be installed and run, for example, on a UNIX-based server, a 
Windows NT-based server, or other server system. Similarly, users may access the 
development and deployment tool from any web browser. 
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[0039] Figure 1 A is a flow diagram showing the steps that may be performed in an 

exemplary web-based software development and deployment tool according to the 
present invention. In step 100, a new project is defined. This step is typically carried 
out by the business or other functional areas within the organization. During this 
step, the end-users define what they what want the new (or updated) software 
application to do. For example, the end-users may want to change an ordering page 
in a web-based store to use a new contract for interfacing with the back-end systems. 
[0040] In step 102, the new (or updated) application is defined. In this step, the 

q organization's development and configuration management groups may meet to 

jE discuss what is required from the development group. The application definition may 

,h 

4 ; include environment definition, release name definition, versioning, build script 

* requirements, and application configuration requirements. This step is preferably 

2 done as early in the development process as possible. Figure IB is a more detailed 

P flow diagram showing the sub-steps that may be performed in embodiments of the 

present invention. Figure 2 is a screen shot showing an exemplary embodiment of a 
development and deployment tool according to the present invention. Figures 3A-19 
are screen shots showing an exemplary user-interface that may be implemented in 
embodiments of the invention to assist users in completing each of the steps in 
Figures 1A and IB. Tables 1 and 2, shown in Figures 20 and 21, respectively, show 
the data that is used in a preferred embodiment when defining the application within 
the software development tool. Table 1 shows the data that may be used to define the 
release and Table 2 shows the data that may be used to define the environment. 
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[0041] In step 200, the release and component data for the new application is defined. 

Figure 3 A shows an exemplary data request screen for completing the first part of this 
task, that is, the definition of the release data. The view shown in Figure 3 A may be 
accessed by selecting option button 8 (shown in Figure 2) to view "CM Admin" drop 
down menu 802 (shown in Figure 8) and selecting the "Add Release" menu item. 
The fields shown in Figure 3 A may be filled in as follows. "Release Name" field 302 
defines how the release/project will be identified within the development and 
u deployment tracking tool. "Release ID" field 304 identifies the directory structure 

p underneath the base directory on the production systems. "Release Version" field 

JC 306 identifies the release version number. For example, the release version number 

£ may have the form: X.X.X, where "X" is an integer. "SUN Package Name" field 308 

q is only used in certain operating environments. The field may be used to identify the 

O base SUN Package name to be used to any SUN packages to be generated within this 

O release. "Source Root Directory" field 3 1 0 identifies the top-level directory for the 

source code. "Source Type" field 312 identifies the source type, for example, 
ClearCase, CCC/Harvest, SourceSafe, and the like. "Source View" field 314 is the 
default view used by the tool to compile any source code for this release. Once the 
data has been filled in, the user may press "Submit" button 3 16 to input the 
information to the development and deployment tracking tool. 
[0042] The second half of step 200 is defining the project data. Figure 3B is shows 

an exemplary user interface for completing this step. As with the view shown in 
Figure 3 A, the view shown in Figure 3B is access by selecting "Add Component" 
from "CM Admin" menu item 802 (shown in Figure 8). The user first selects the 
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release from drop-down menu item 320. When this menu is selected, all previously 
defined releases are provided as options. The user then selects a platform using drop- 
down menu item 322. The platform is the type of application server. Examples of 
platforms include, iPlanet Web Server, iPlanet Application Server, BEA Application 
Server, and the like. "Component Name" field 324 may comprise a derivative of the 
release name together with a suffix reflecting the platform. Examples of suffixes 
include, NAS, Cnt, Web, and IAS for the web and application servers. "Build Script 
Directory" field 326 is the directory where the build script/make file resides to build 
this component. "Build Script Name" field 328 is the actual name of the build 
script/make file. "Script Type" field 330 is the type of script being used (for 
example, UNIX shell script, GNU Makefile, ANT script, and the like). Once the data 
has been filled in, the user may press "Submit" button 332 to input the information to 
the development and deployment tracking tool. 
[0043] In step 202 the project environment data is defined. Figure 4 shows an 

exemplary user interface that may be implemented to collect this data from a user. 
The environment can be thought of as a placeholder that defines a set of machines (or 
nodes) that a release/application executes on. Each release/application will migrate 
through a set of environments. Again, this interface may be accessed from "CM 
Admin" drop down menu 802 by selecting the "Add Environment" menu item. 
"Environment Name" field 402 should reflect the type of environment and platform 
that makes up this environment, (e.g., CommonDevNas40). "Environment Type" 
field 404 provides a list of pre-defined environments that are tracked using the 
development and deployment tracking tool. Once the data has been filled in, the user 
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may press "Submit" button 406 to input the information to the development and 
deployment tracking tool. 

In step 204, the build processes and platforms are defined. The build script is 
an integral part of the process to get an application ready to use the tool. In a 
preferred embodiment, a development and deployment tracking tool provides a 
developer with multiple options for completing the build script. For example, an 
embodiment may allow use of a simple Korn shell script; the GNU make utility, and 
the ANT utility. Preferably, the build script is able to accept arguments that allow the 
tool to build individual components separate from each other. Also, the build script is 
preferably capable of using environment variables defined outside itself. 

Also in step 204, the build platform (including node data) is defined. The 
node data is part of the environment data. An environment is defined as a set of 
nodes that an application executes on. The node data describes these machines, and 
gives the development and deployment tool information needed for file transfers 
(FTP), restarts of application servers, and application base directories. When the user 
selects the "Add Node" menu item from "CM Admin" drop down menu 802, a view 
such as shown in Figure 5 may be provided to the user. 

When a node is added, the user must bind an environment to the node. 
"Environment" drop-down list 502 provides a list of pre-defined environments from 
which to choose for this purpose. The user then selects a platform type, determined 
by the nodes functionality, from "Platform" drop-down list 504. "Node Name" field 
506 is used to identify the node. The field may comprise the hostname of the 
computer on the network or a nickname used to identify the node. "Host Computer 
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Name" field 508 is the hostname of the computer on the network. "Root User" field 
510, "Root Password" field 512, and "Root Directory" field 514 correspond to the 
user that has the rights to the third-party application's startup and shutdown scripts. 

"FTP Port" field 516 may be used if a non-standard port is used by the 
development and deployment tool. If a standard port is to be used, the field need not 
be included. "Domain Name" field 518 identifies the domain that the computer 
resides in. Once the data has been filled in, the user may press "Submit" button 520 
to input the information to the development and deployment tracking tool. 

Once all of the needed environments are defined, the deployment chain is 
defined in step 206. A deployment chain is the route of environments that an 
application must follow on its way from development to production. A simple 
example of a deployment chain is as follows: 

1 . An application release is built and deployed to System Test ("systest"). 

2. Once approved in System Test, the same build would be deployed and 
installed on a Pre-Production environment. 

3. Once approved in Pre-Production, the same build would then be deployed 
to the Production environment. 

Each environment is defined within the tool. These environments in the development 
chain may be changed on the fly, to easily accommodate changes in deployment 
requirements. Figures 6A and 6B are screen shots of exemplary forms for creating or 
updating an environment chain table. A user first identifies the release in dropdown 
menu 600, then click on submit button 602 to display a form such as shown in Figure 
6B. The current environment chain 604 for the release in this example includes two 
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stages: a common development environment and a system test environment. Using 
option buttons 606, the user modifies the environment chain to insert other 
environments before or after those already included in the chain. The user may also 
delete or edit existing entries in the chain. As before, the user click on submit button 
608 to enter the requested changes. 
[0049] The final sub-step in the application definition phase is step 208, where users 

are added and/or updated to provide them with access to the development and 
deployment tool. A user profile may be added to the development and deployment 
% tool by selecting the "Add User Profile" menu item from "CM Admin" drop down 

i menu 802 to display a form such as shown in Figure 7A. 

kin 

jp [0050] "CUID" field 702 corresponds to the user's userlD on the computer system, 

1 while "First Name" field 704 and "Last Name" field 706 correspond to the user's 

;i - •: 

^ given name and surname. Fields 708 and 710 may be used to enter the user's email 

n interactive pager addresses. These addresses may be used by embodiments of the 

development and deployment tool to send email notification messages to the user. 
Field 712 sets the default number days back that a component is displayed on the 
build request status screen. For example, if it is set to "30" the build request status 
screen will show components from the preceding thirty days. 
[0051] Users of the development and deployment tool may be categorized according 

to the role they have in the development and deployment process. Roles may include, 
for example, "developer" (DEV), "configuration manager" (CM), "quality assurance" 
(QA), and the like. Within the development and deployment tool, a user's assigned 
role determines that user's authorization to perform certain tasks. In a preferred 
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embodiment, a CM role is the highest level Accordingly, in such embodiments, a 
user assigned the CM role may perform all of the functions in the system. Drop- 
down list 714 may be used to identify the new user's assigned role. Once the data has 
been filled in, the user may press "Submit" button 716 to input the information to the 
development and deployment tracking tool. 

A user profile may be updated in much the same manner by selecting the 
"Update User Profile" menu item from "CM Admin" drop down menu 802 to display 
a list of users such as shown in Figure 7B. Once the user to be updated is selected 
from this list, a form similar to the form shown in Figure 7A is provided. Changes 
are entered and submitted as described above. 

Referring back to Figure 1, the next step in the development and deployment 
process is step 103, where the software developers actually write the code. This step 
may include any suitable code- writing techniques and may involve numerous 
developers in collaboration or a single developer. 

In step 104, the developers unit test the new code to ensure it provides the 
functionality defined in steps 100 and 102. This testing is generally performed in 
isolation, that is, the testing goal need not include testing the new code's interaction 
with other software components. The development and deployment tool is used to 
create a "sandbox" environment in which to complete this testing. A sandbox 
environment is a unit testing system allowing a developer to build as many times as 
he deems necessary without CM assistance. The developer selects "Build" button 9 
(shown in Figure 2) to access "Build" menu 902 (as shown in Figure 9). The 
developer then selects "Build To Sandbox" from menu 902 to receive a view such as 
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shown in Figure 1 0. The developer then selects the release to be tested in the 
sandbox via drop-down list 1002 and submits the request via "Submit" button 1004. 
After submitting the request, additional build information is gathered via a view such 
as shown in Figure 1 1 . 

[0055] Additional build information collected by the development and deployment 

tool include the component to be tested and the environment in which to perform the 
testing. This information is entered via drop-down lists 1 102 and 1 104. Additionally, 
a new source view may be entered into option box 1 106. Again, the developer 
submits the information using "Submit" button 1 108. At this point, the development 
and deployment tracking tool will compile the necessary code, deploy it to the correct 
environment and install the software in the environment. The code may be bundled 
into single file for transport to the environment using suitable file compression tools, 
such as, for example, a tar utility on a UNIX-based system , a ZIP utility for other 
operating systems, and the like. The bundled file may then be transferred to the target 
environment using any suitable file transmission protocol, for example, FTP, copy, 
and the like. Once the transfer is complete, the development and deployment tool 
unbundles the files and stores them in the correct directories or folders and makes any 
system changes needed to complete the installation process. 

[0056] Once the developer is satisfied with the unit testing of the new application, he 

must submit the application for testing in an integrated environment in step 106. This 
testing generally done under the developer's control or the control of the developer's 
group. This integrated testing environment is also referred to herein as "common 
development" or "common dev." Building to the common development environment, 
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is the first step in moving a release to production. The common development 
environment is the first place that application packaging and the application directory 
structures match those in the production environment. This is also where build rules 
and CM processes are enforced by the development and deployment tool That is, 
once an application component is built to a common development environment, it 
cannot be built again until the component has a status of "FAILED", "Rejected", or 
"in Production". In a preferred embodiment, only users assigned a role of 
"developer" or "CM" may build to a common development environment. 

[0057] The development and deployment tool facilitates this step in much the same 

manner as it facilitates the unit testing (i.e., build to sandbox). That is, the developer 
selects "Build To Common Dev" from "Build" menu 902 (as shown in Figure 9). 
When this option is selected, a view such as shown in Figure 12 is displayed (this 
view is similar to that shown in Figure 10). The developer then selects the release to 
be tested in common development via drop-down list 1202 and submits the request 
via "Submit" button 1204. After submitting the request, the component to be tested is 
selected from drop-down list 1302 in a view such as shown in Figure 13. Again, the 
developer submits the information using "Submit" button 1304. Unlike the sandbox 
build request, when building to the common environment, the user cannot specify an 
overriding view to use. Similarly, the user cannot change the environment, which is 
defined in the environment chain table within the tool. 

[0058] Common development testing is typically conducted by an integration test 

team. Such a team may consist of QA and development members or only 
development members. Because the impacts of multiple simultaneous tests in a 
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single environment may play havoc with testing there is typically a coordination 
between the teams to make sure everything goes smoothly. The development and 
deployment tool controls the versions of the code in the common development 
environment. 

[0059] The integration test team tests the component within the common 

development environment and "grades" the application with a "pass" or "fail" status 
in step 110. If the application fails the common development test, the application is 
sent back to step 103 where the developer corrects any problems. If the application 
receives a passing grade then configuration management sends the application on for 
system testing in step 112. Again, the development and deployment tool facilitates 
these steps by providing an approval process. The evaluator accesses an approval 
form such as shown in Figure 14 by selecting button 10 (shown in Figure 2). 

[0060] This form is used throughout the development and deployment process to 

approve or reject a software component that has been placed into a testing status. The 
evaluator selects the release using drop-down list 1402 and issues the grade via one of 
status options 1404. Finally, the evaluator may add comments in textbox area 1406. 
In some embodiments, the comments field may be mandatory in all cases. In other 
embodiments, the comments field may be mandatory only when the component 
receives a failing grade or only when the component receives a passing grade. In 
other embodiments, the comments may be completely optional. 

[0061] As described above, if the component is approved the process moves on to 

step 112 where the application is deployed for system testing. The purpose of the 
system testing is to check the application for functionality and operability in a test 
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environment. Such testing is typically performed by a quality assurance (QA) group, 
separate from the development group. The application is deployed to the test system 
by selecting button 15 (shown in Figure 2) and choosing option "Deploy to SysTest" 
from menu 1502 (shown in Figure 15). When this option is selected, a form such as 
shown in Figure 1 6 is presented to the user. The user then selects the component to 
be tested in the system test via drop-down list 1602 and submits the request via 
"Submit" button 1604. Drop-down list 1602 displays all components that are ready 

E s and available to be pushed to system test environment. Again, the developer submits 

p the information using "Submit" button 1 604. 

JE [0062] In step 1 14 (shown in Figure 1) the application undergoes system testing to 

*P verify the application's functionality as described above. In step 1 16, the evaluators 

grade the application's performance using a view such as shown in Figure 14. If the 

S application fails this testing, it is sent back to the application developers in step 103. 

p Otherwise, the application is ready for deployment to a pre-production system in step 

118. In a preferred embodiment, a pre-production system replicates as much of the 
operational (i.e., production) system as possible. One purpose of testing the 
application in a pre-production environment is to optimize the performance of the 
application and to ensure that the application will be durable when it is moved to the 
operation environment. 
[0063] The development and deployment tool is used by the configuration 

management group to deploy the application to the pre-production system. This is 
accomplished by selecting button 15 (shown in Figure 2) and choosing option 
"Deploy to Pre-Production" from menu 1502 (shown in Figure 15). When this option 
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is selected, a form such as shown in Figure 17 is presented to the user. This form is 
essentially the same as that shown in Figure 16, except that the component selected in 
drop-down list 1602 will be built for the pre-production equipment. 
[0064] In step 120, the new application is tested on the pre-production equipment. In 

step 122, the evaluators grade the application as described above. If the application 
passes the pre-production equipment test, the final step is to deploy the application to 
the production system in step 124. Otherwise, if the application fails the pre- 
production testing, it is sent back to the application developers in step 103. 
[0065] The production deployment is processed by the development and deployment 

tool in much the same way as previously described herein. That is, a configuration 
management user selects button 15 (shown in Figure 2) and chooses option "Deploy 
to Production'' from menu 1502 (shown in Figure 15). When this option is selected, a 
form such as shown in Figure 1 8 is presented to the user. This form is essentially the 
same as that shown in Figures 16 and 17, except the component selected in drop- 
down list 1702 will be built for the production equipment. 
Other Features In A Preferred Embodiment 
[0066] A development and deployment tracking tool according to the present 

invention may include many other features to ease the configuration control and 
management tasks. For example, the tool may provide status reports or other 
information that may be customized on demand by individual users. The view shown 
in Figure 2 is an example of one such report. In this example, the report is generated 
when a user selects button 12 (in Figure 2) to receive "Build Status" information. 
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That report includes several columns of information related to the different 
components being managed by the tool. 

Such a report may be customized in this embodiment by selecting button 13 
(in Figure 2) to access the "Modify Profile" function of the tool A screen such as 
shown in Figure 19 will be provided to the user. "Number of Days" textbox 1902 is 
used to modify the data that the user will see on the "Build Status Report" page. The 
tool subtracts the number of days in this field from the current date and displays only 
the requests that have been made within that time frame. "Release Names" multiple 
select box 1904 allows the user to select which releases should be displayed in the 
report. 

Many of the options available through the Configuration Management Admin 
button (i.e., button 8 on Figure 2) have already been described herein. Additional 
options may be provided allowing a user to update information already stored in the 
database. For example, forms may be provided to update release data, component 
data, environment data, node data, and user profiles. 

Other features may be included in embodiments of the present invention to 
simplify maintenance and troubleshooting within the development and deployment 
tracking tool. For example, the system may include error logs, and other such 
utilities. 

The foregoing disclosure of the preferred embodiments of the present 
invention has been presented for purposes of illustration and description. It is not 
intended to be exhaustive or to limit the invention to the precise forms disclosed. 
Many variations and modifications of the embodiments described herein will be 
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apparent to one of ordinary skill in the art in light of the above disclosure. The scope 
of the invention is to be defined only by the claims appended hereto, and by their 
equivalents. 

Further, in describing representative embodiments of the present invention, 
the specification may have presented the method and/or process of the present 
invention as a particular sequence of steps. However, to the extent that the method or 
process does not rely on the particular order of steps set forth herein, the method or 
process should not be limited to the particular sequence of steps described. As one of 
ordinary skill in the art would appreciate, other sequences of steps may be possible. 
Therefore, the particular order of the steps set forth in the specification should not be 
construed as limitations on the claims. In addition, the claims directed to the method 
and/or process of the present invention should not be limited to the performance of 
their steps in the order written, and one skilled in the art can readily appreciate that 
the sequences may be varied and still remain within the spirit and scope of the present 
invention. 
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